home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 7727 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.0 KB

  1. Path: news.interpath.net!mercury!softbase
  2. From: softbase@mercury.interpath.net (Scott McMahan - Softbase Systems)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: [Perf:] mem*() procs vs. array looping
  5. Date: 28 Feb 1996 13:57:56 GMT
  6. Organization: Interpath -- Providing Internet access to North Carolina
  7. Message-ID: <4h1n14$3b3@news.interpath.net>
  8. References: <4glkq1$gu7@gazette.tandem.com>
  9. NNTP-Posting-Host: mercury.interpath.com
  10. X-Newsreader: TIN [version 1.2 PL2]
  11.  
  12. Francis E. Chang (francis@patch.tandem.com) wrote:
  13.  
  14. : Are mem*() procedures performance boosters?
  15.  
  16. I have had some experience with this exact question, and want to 
  17. share what I found out.
  18.  
  19. 1. The only real answer is, "it depends". It depends on who wrote the
  20. stdlib routines, how conscientious they were, how much they knew about
  21. the hardware they were writing on, etc. From one library to the
  22. next, the answer could change.
  23.  
  24. 2. The only way to tell is on a per-stdlib basis! Measuring execution
  25. of the program in a proflier for every different memxxx in every
  26. different library. You *have* to profile the program and see what
  27. is going on. Does calling memxxx even matter in the overall scheme?
  28.  
  29. 3. Most if not all commercial compilers will write things like memcpy
  30. in assembly language, and some processors have native instructions for
  31. doing memory copies and stuff that make them much faster than any C
  32. code you could write, because they don't have to continually load
  33. addresses like you do in a loop.
  34.  
  35. 4. I had a program where memset was THE bottleneck, taking up more time
  36. than I/O. I re-wrote a memory zeroing function using the most unrolled,
  37. efficient loop I could write, and it was still orders of magnitude
  38. slower than the system memset.  No way I could make it faster in C.
  39.  
  40. 5. WRT #4, I removed the memset. It was initializing a buffer, and I
  41. said "forget it" and used the uninitialized buffer and took my chances.
  42. Changing the design was more effecient than coding hokey
  43. optimizations! After removing memset, I/O functions accounted for
  44. 90% or more of the time spent in the program, which I could live with.
  45.  
  46. Scott
  47.  
  48.